Also, ich begrüße Sie zur Vorlesung der Rechneraktur die Woche.

Gut, wo ist, so weit glaube ich, von administrativen Übungen und Rechnerübungen ist so weit,

glaube ich, alles geklärt.

Okay, gut.

Dann, wo sind wir letzte Woche angekommen?

Also wir hatten uns jetzt mit diesen CISC und RISC Prozessoren auseinandergesetzt und wir

sind jetzt also bei den RISC Prozessoren angelangt.

Um es nochmal zu wiederholen, das Problem bei den RISC Prozessoren, bzw. fangen wir

erstmal mit den Vorteilen an, das angenehme an den RISC Prozessoren ist ja, dass wir Pipeline

extrem, Pipeline extrem ausnutzen können und im Idealfall könnten wir damit einen Speedup

gegenüber einer nicht, einem Rechenwerk oder einem Prozessor, der nicht mit Pipelining

arbeitet, einen Speedup um Faktor k, also k mal schneller werden, wenn wir k Phasen

hätten, also k einzelne Abschnitte in unserer Pipeline.

So, das werden wir aber maximal, das wäre dann das Maximale, was wir erreichen könnten,

das werden wir aber nicht schaffen, denn da sprechen eben die sogenannten Hesserts dagegen

und bei diesen Hesserts hat man Unterschiede zwischen den Struktur Hesserts, also Befehle,

die gleichzeitig auf gleiche Ressourcen benötigen, gleiche Ressourcen zugreifen möchten, also

beispielsweise Speicher oder auch ein Rechenwerk.

Ich kann also im einfachsten Fall drei Additionsbefehle nicht gleichzeitig ausführen auf einer superskalaren

Prozessoreinheit, wenn ich nur zwei Rechenwerke zur Verfügung habe.

Dann geht es nicht.

Ja, und dann haben wir uns beschäftigt, dann habe ich gesagt, es gibt Datenhesserts, das

soll heute in der Stunde Thema sein und wir waren bei diesen Sprunghesserts.

Sprunghesserts sind also die Probleme, die ergeben sich, wenn die Pipeline die einzelnen

Befehle abarbeitet und wir haben einen bedingten Sprungbefehl, das heißt also die Ausführung

des nächsten Befehls hängt von einer Bedingung ab.

Wir müssen also eine Adresse, unter Umständen müssen wir den Adresszähler, den Programmzähler

neu laden, weil der nächste auszuführende Befehl nicht der ist, der unmittelbar nach

diesem Sprungbefehl folgt.

Also wir müssen eben weiterspringen.

Problem ist, dass wir diese Auswertung der Bedingungen in der Exekutionsphase in unserer

Pipeline haben und die ist in der Regel immer weiter hinten.

Das heißt also es gibt eine Anzahl von Stufen in unserer Pipeline, wo wir Befehle reinladen

und wissen nicht genau, ob das wirklich die richtigen sind, weil wir nicht wissen, ob

wir springen müssen oder nicht.

Und das erfahren wir dann eben erst dann, wenn die Bedingung ausgewertet ist.

So, soweit so gut, da was kann man dagegen tun, dann haben wir uns mit der dynamischen

Sprungvorhersage mit statischer und dynamischer Sprungvorhersage auseinandergesetzt.

Statische Sprungvorhersage gab es Branch taken, Branch not taken oder Branch by opcode.

Bei der statischen Sprungvorhersage kommen wir so bis maximal 75%, wo wir richtig liegen.

Bei unserer Vorhersage mit der dynamischen werden wir besser, wir können also weit über

90% erreichen.

Und die dynamische Vorhersage nutzt vor allen Dingen aus dem Umstand, dass wir in Schleifen

immer wieder zurückspringen und ich hatte Ihnen also gezeigt, wie die Sache mit diesen

Historie-Bits läuft, also dass man für jeden Sprungbefehl die Vorgeschichte aufzeichnet

anhand von ein paar Bits, die jedem einzelnen Sprungbefehl zugeordnet sind.

Ach ja, genau, da fällt mir noch ein, genau, irgendjemand hat die Frage gestellt und da

gibt es also diese Branch-Historie-Tabellen, wie viele Einträge das es denn da geben kann

und das habe ich mittlerweile recherchiert, es sind tatsächlich so maximal 512, mit maximal

512 gibt es Untersuchungen, dass ich dann schon 96% richtig liege und wenn ich mehr Einträge